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Abstract 

There  is  an  increasing  need  within  the  Navy  and 
Marine  Corps  for  building  distributed  situation-aware 
applications  that  are  rapidly  reconfigurable  and  sur- 
vivable  in  the  face  of  attacks  and  changing  mission 
needs.  For  the  Navy’s  vision  of  Network  Centric  War¬ 
fare  and  the  Total  Ship  Computing  Environment  to 
succeed,  there  is  an  urgent  need  for  a  secure,  robust, 
and  survivable  network  infrastructure  for  disseminat¬ 
ing  mission-critical  information  in  a  timely  manner. 
It  is  widely  believed  that  intelligent  software  agents 
provide  the  ability  to  build  robust,  agile,  and  efficient 
distributed  applications.  We  outline  how  Secure  In¬ 
frastructure  for  Networked  Systems  (SINS)  being  de¬ 
veloped  at  the  Naval  Research  Laboratory  will  provide 
commanders  and  warfighters  the  necessary  middleware 
for  constructing  situation-aware  Command  and  Con¬ 
trol  (C2)  and  combat  applications.  We  pay  particu¬ 
lar  attention  to  the  correctness,  survivability,  and  effi¬ 
ciency  of  the  underlying  middleware  architecture,  and 
develop  a  middleware  definition  language  Secure  Op¬ 
erations  Language  (SOL)  that  enables  C2  and  Combat 
applications  to  use  this  infrastructure  in  a  seamless  and 
scalable  manner. 


1  Introduction 

Efforts  are  underway  at  the  Department  of  Defense 
(DoD)  for  developing  new  technologies  to  create  more 
effective  sensor  and  communications  architectures,  en¬ 
abling  the  Forces  to  create  and  exploit  a  common 
situational  awareness  and  increase  the  speed  of  com¬ 
mand  and  response.  Termed  Network  Centric  War¬ 
fare  [6],  this  technology  will  provide  warfighters  with 
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a  new  type  of  information  advantage,  broadly  charac¬ 
terized  by  significantly  improved  capabilities  for  shar¬ 
ing  and  accessing  information.  A  recent  DoD  report 
to  Congress  [Network  Centric  Warfare;  Department  of 
Defense  Report  to  Congress,  27th  July,  2001]  identi¬ 
fies  the  following  major  technical  and  administrative 
impediments  to  progress  in  Network  Centric  Warfare: 

•  the  lack  of  secure,  robust  connectivity  and  inter¬ 
operability  and 

•  the  lack  of  technology  investments  in  Network 
Centric  Warfare. 

Not  only  is  robust  connectivity  important,  but  it 
is  also  imperative  for  the  Information  Network  infras¬ 
tructure  to  provide  commanders  with  a  situational 
awareness  of  their  assets  in  the  information  battle- 
space  and,  in  addition,  to  deny  adversaries  access  to 
this  information.  For  the  vision  of  Network  Centric 
Warfare  to  become  a  reality  the  DoD,  including  the 
Navy  and  Marine  Corps,  requires  a  network  infrastruc¬ 
ture  for  disseminating  mission-critical  information  in 
a  secure  and  timely  manner.  This  is  extremely  diffi¬ 
cult  to  achieve  at  present  because  Commercial  Off  The 
Shelf  (COTS)  products  and  legacy  systems  cannot  pro¬ 
vide  fine-grained  separation  of  classified  data.  Hence, 
this  data  is  currently  treated  at  the  highest  classifica¬ 
tion  level.  This  leads  to  unnecessary  downgrading  of 
information-carrying  data.  Because  current  downgrad¬ 
ing  technology  is  unsophisticated  and  easily  defeated 
by  steganography  and  other  clever  coding  schemes,  the 
data  is  vulnerable  to  access  by  adversaries. 

Another  important  requirement  is  rapid  reconfig¬ 
urability  of  the  networked  battle-space  to  satisfy  the 
needs  of  new  missions.  This  requirement  is  especially 
difficult  to  achieve  in  a  coalition  setting,  where  the 
need  exists  for  interoperability  between  diverse  systems 
and  platforms  and  where  the  needs  of  the  coalition 
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partners  are  in  a  constant  flux.  Also  needed  at  the 
user  level  is  programmability  of  the  underlying  appli¬ 
cation,  such  as  a  distributed  mission  planning  system 
or  a  network  centric  Command  and  Control  ( C 2)  for 
combat  application,  with  a  rapid  turnaround  time.  As 
demonstrated  by  mission  planning  in  recent  Naval  mis¬ 
sions,  current  turnaround  times  are  measured  in  days 
or  weeks,  rather  than  hours,  and  mission  planning  may 
involve  hundreds  of  technical  personnel  working  into 
the  early  morning  hours.  For  Network  Centric  War¬ 
fare  to  succeed,  the  lengthy  time  and  massive  human 
resources  needed  to  respond  to  new  missions  must  be 
significantly  decreased. 

The  ubiquity  of  the  Internet  and  networking  infras¬ 
tructure,  and  the  DoD’s  increasing  reliance  on  com¬ 
puter  networks  for  force  coordination,  mission  plan¬ 
ning,  and  mission  definition,  have  created  the  need  for 
a  high  assurance  distributed  computer  platform  which 
is  secure,  reconfigurable,  and  survivable.  The  benefits 
of  Network  Centric  Warfare  can  be  realized  only  af¬ 
ter  we  address  associated  new  security  threats,  both 
from  malicious  agents  as  well  as  untrusted  or  compro¬ 
mised  hosts.  The  goals  of  Network  Centric  Warfare 
and  the  Total  Ship  Computing  Environment1,  which 
are  gaining  prominence  within  the  Navy  and  Marine 
Corps,  will  not  be  met  if  inadequate  attention  is  paid 
to  network  and  information  security.  Distributed  com¬ 
puting  will  never  gain  wide  acceptance  if  the  associ¬ 
ated  middleware  is  unreliable  and  does  not  include  ca¬ 
pabilities  to  defend  and  protect  vital  information  re¬ 
sources  [7].  There  is  growing  awareness  within  the  de¬ 
fense  research  and  development  community  that  de¬ 
veloping  the  next  generation  of  sensor-rich,  massively 
distributed  autonomous  systems  will  require  a  total 
paradigm  shift  in  terms  of  the  capabilities,  processes, 
and  architectures  used  to  mitigate  threats,  plug  vul¬ 
nerabilities,  and  provide  countermeasures. 

The  goal  of  the  NRL  Secure  Agents  project  [5]  is 
to  develop  a  Secure  Infrastructure  for  Networked  Sys¬ 
tems  (SINS).  It  is  widely  acknowledged  that  intelligent 
software  agents  are  central  to  the  success  of  Network 
Centric  Warfare.  This  is  because  agents  are  agile  and 
provide  an  efficient  and  survivable  paradigm  for  infor¬ 
mation  distribution  and  access.  Agents  are  efficient 
because  only  relevant  information  gets  passed  along. 
They  are  survivable  because  they  are  distributed.  This 
new  technology,  which  includes  both  autonomous  and 
mobile  agents,  addresses  many  of  the  challenges  posed 
by  Network  Centric  Warfare.  SINS  is  a  middleware 
based  on  distributed  agent  technology.  This  middle¬ 
ware  provides  the  required  degree  of  trust  in  addition 

1The  computing  environment  for  the  DD(X)  family  of  the 
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to  meeting  a  set  of  achievable  security  requirements. 
Such  an  infrastructure  is  central  to  the  successful  de¬ 
ployment  and  transfer  of  agent  technology  to  the  Fleet 
because  security  is  a  necessary  prerequisite  for  Network 
Centric  Warfare. 

The  SINS  project  specifically  addresses  the  following 
issues  central  to  the  effectiveness  and  security  of  a  dis¬ 
tributed  agent  architecture:  (a)  trustworthiness  of  the 
agents,  (b)  trustworthiness  and  timeliness  of  informa¬ 
tion  gathered  by  the  agents,  (c)  secure  and  timely  prop¬ 
agation  of  information  collected  by  the  agents  to  the 
appropriate  locations,  (d)  sharing  of  information  from 
diverse  sources,  (e)  sharing  of  information  at  differ¬ 
ent  classification  levels  in  a  Multi  Level  Secure  (MLS) 
environment,  (f)  more  efficient,  secure  use  of  the  lim¬ 
ited  Fleet  communication  resources,  (g)  collection  of 
statistical  data  required  to  make  correct  tactical  re¬ 
sponses,  (h)  allowing  tactical  decision-making  and  re¬ 
sponses  from  lower-level  authorities,  and  (i)  State-of- 
the-art  visualization  techniques  and  tools  for  the  com¬ 
mand  center. 

In  a  globally  connected  environment,  computer- 
related  attacks  affect  not  only  the  host  computer  that 
is  being  attacked  (or  being  used  as  a  launch  pad),  but 
the  network  it  is  part  of,  not  to  mention  the  global  in¬ 
frastructure  as  a  whole.  Moreover,  these  attacks  take 
only  seconds  or  minutes  to  propagate  and  wreak  havoc, 
unlike  traditional  tools  of  conventional  or  propaganda 
warfare  that  could  take  days  or  months  to  take  effect. 
Therefore,  current  strategies  in  information  warfare  or 
Network  Centric  Warfare  require  fast  detection  of  pos¬ 
sible  attacks,  fast  comprehension  of  the  overall  situa¬ 
tion,  and  immediate  and  accurate  responses  and  coun¬ 
termeasures  to  the  situation.  Tools  built  to  support 
these  strategies  should  also  provide  the  flexibility  and 
security  services  needed  to  ensure  fast  deployment,  and 
secure  communication  between  network  hosts.  The 
SINS  infrastructure  serves  as  enabling  technology  for 
network  situational  awareness.  We  address  the  infras¬ 
tructure  monitoring  problem  with  the  novel  concept  of 
security  agents,  which  police  the  network,  identify  vul¬ 
nerabilities,  attacks,  and  compromised  network  com¬ 
ponents,  and  install  effective  countermeasures  (such  as 
rollback  recovery,  fail  over  recovery  across  domains, 
etc)  to  effectively  deal  with  the  problem. 

2  Technical  Approach 

The  goal  of  the  SINS  project  at  NRL  is  to  develop 
enabling  technologies  and  architectures  to  support  a 
secure  and  reconfigurable  infrastructure  for  networked 
C 2  for  combat  systems  and  network  situational  aware¬ 
ness.  The  results  of  this  research  will  enable  us  to 
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build  a  network  centric  infrastructure  for  C 2  for  com¬ 
bat  applications  to  support  the  mission-critical  needs 
of  the  Navy.  Such  an  infrastructure  is  central  to  the 
successful  deployment  and  transfer  of  network  centric 
warfare  technologies  to  the  Fleet  because  a  secure  and 
flexible  network  infrastructure  is  a  necessary  prereq¬ 
uisite  for  Network  Centric  Warfare.  To  address  the 
security  issue,  we  have  developed  the  novel  approach 
of  security  agents  [5]  based  on  the  notion  of  enforce¬ 
able  security  policies  of  Fred  Schneider  [1,  11],  to  police 
the  network  infrastructure  of  distributed  C2  applica¬ 
tions  such  as  systems  for  distributed  decision  support 
and  distributed  mission  planning.  By  using  agent  au¬ 
tonomy  and  mobility  to  our  advantage,  we  ameliorate 
the  security  and  safety  vulnerabilities  associated  with 
agent  technology.  Security  agents  protect  a  network 
against  Information  Warfare  (IW)  attacks  by  includ¬ 
ing  key  security  features  such  as  encryption,  authen¬ 
tication,  virus  checking,  compliance  checking,  and  in¬ 
trusion  detection.  Security  agents  are  therefore  the  en¬ 
abling  technology  that  give  application  developers  the 
ability  to  deploy  network  centric  systems  which  are  se¬ 
cure  and  survivable,  in  a  cost-effective  and  timely  man¬ 
ner. 

Since  security  agents  have  more  privileges  than  se¬ 
cure  agents,  we  have  to  provide  assurance  that  their 
behavior  will  be  safe.  We  have  developed  a  special- 
purpose  specification  language  Secure  Operations  Lan¬ 
guage  (SOL)  [3]  to  help  provide  this  assurance.  We 
are  developing  a  SOL  verifier  (SOLver)  to  establish 
(with  mathematical  certainty)  the  compliance  of  secu¬ 
rity  agents  with  their  goals.  We  can  also  ensure  that 
the  behavior  of  security  agents  satisfies  key  security  and 
safety  properties  [2].  The  following  technical  issues  [9] 
are  being  addressed  in  the  SINS  project: 


•  Consistency  of  security  agent  behavior 

•  Secure  Operations  Language  (SOL) 

How  to  make  SOL  agents  composable,  safe, 
and  secure 

Proofs  that  SOL  security  agents  enforce  re¬ 
quired  security  policies 

•  Issues  concerning  Security  Agents: 

Authorization  agents 
Crypto  assist  agents 
Policy  enforcement  agents 
Secure  agents  monitoring 

•  Application-specific  security  agents: 


Intrusion  detection 
Application  monitoring 
Survivability  (adaptability) 

Providing  secure,  safe,  mobility  of  agent  code 
Making  sure  security  agents  enforce  a  consis¬ 
tent  security  policy 

Network  Situational  Awareness  and  infras¬ 
tructure  monitoring 

Developing  a  “Consistent  Operational  Pic¬ 
ture”  for  Information  Networks 

The  Secure  Infrastructure  for  Networked  Systems 
(SINS)  and  its  associated  Agent  Creation  Environment 
(ACE)  are  designed  to  explicitly  solve  the  security 
problems  described  above  and  other  related  problems 
of  agent  creation  and  deployment.  Security  is  our  pri¬ 
mary  concern.  However,  while  addressing  security,  we 
also  intend  to  address  problems  of  efficiency,  reconfig¬ 
urability,  and  survivability.  Reconfigurability  in  ACE 
is  supported  by  agent  templates  and  other  visual  aids 
such  as  graphical  visualization  tools  to  ease  the  agent 
creation  and  customization  processes.  SINS  provides 
role-based  access  control  and  management  in  addition 
to  trust  management.  SINS  will  also  include  functions 
for  intrusion  detection  and  tolerance.  SINS  is  designed 
for  survivability  and  will  support  Multi-Level  Secure 
(MLS)  access  and  authentication.  ACE  supports  vi¬ 
sual  Secure  Operations  Language  (vSOL),  a  flexible 
and  powerful  notation  in  which  to  express  the  logic 
associated  with  an  agent.  For  more  details  see  [2,  3]. 


Figure  1.  Architecture  of  SINS. 

Figure  1  shows  the  architecture  of  SINS.  Agents 
are  distributed  over  one  or  more  Hosts,  each  of  which 
runs  one  or  more  Agent  Interpreters  (AI),  that  execute 
agents  in  compliance  with  a  set  of  Security  Policies. 
Agents  are  created  using  special-purpose  templates  in 
ACE  (not  shown),  and  are  translated  into  SOL.  Agents 
may  be  created  on  any  host.  Agent  Interpreters  com- 
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municate  among  themselves  using  a  lightweight  proto¬ 
col  similar  to  XML/SOAP  [13],  over  secure  channels, 
with  strong  encryption  using  a  Public  Key  Infrastruc¬ 
ture  (PKI).  For  details  of  the  SINS  inter-agent  proto¬ 
col,  see  [12].  Our  goal  is  to  build  a  secure,  survivable 
agent  infrastructure  that  permits  the  Fleet  to  use  com¬ 
mercial  products  safely.  Hosts  may  run  a  COTS  oper¬ 
ating  system  such  as  Solaris  or  Windows,  or  a  trusted 
operating  system  such  as  secure  Linux  (a  product  of  the 
National  Security  Agency)  or  secure  Solaris.  We  shall 
also  investigate  the  use  of  other  secure  COTS  com¬ 
ponents  such  as  the  secure  Java  Virtual  Machine  and 
other  secure  interpreters,  as  well  as  secure  protocols 
that  harness  a  public  key  infrastructure  to  distribute 
keys  among  interpreters  and  to  authenticate  agents. 

2.1  Network  Infrastructure  for  C 2  Systems 

In  a  globally  connected  environment,  computer- 
related  attacks  affect  not  only  the  host  computer 
that  is  being  attacked  (or  being  used  as  a  launch 
pad),  but  the  network  it  is  part  of,  not  to  mention 
the  global  infrastructure  as  a  whole.  Moreover,  these 
attacks  take  only  seconds  or  minutes  to  propagate  and 
wreak  havoc,  unlike  traditional  tools  of  information 
warfare  that  could  take  days  or  months  to  take  effect. 
Therefore,  current  strategies  in  information  warfare 
or  Network  Centric  Warfare  require  fast  detection  of 
possible  attacks,  fast  comprehension  of  the  overall 
situation,  and  immediate  and  accurate  responses  and 
countermeasures  to  the  situation.  These  tools  should 
also  provide  the  flexibility  and  security  services  needed 
to  ensure  fast  deployment,  and  secure  communication 
between  agents. 

We  address  the  following  issues  in  SINS: 

•  Trustworthiness  of  agents:  We  provide  formal  ar¬ 
guments  (proofs  of  correctness)  for  security  agents 
that  monitor  the  network  infrastructure  and  im¬ 
plement  the  required  security  doctrine  in  case  of 
an  attack. 

•  Trustworthiness  and  timeliness  of  information 
gathered  by  agents:  Information  gathered  by 
agents  can  come  from  various  sources,  requiring 
a  method  to  identify  friend  vs  foe,  and  a  way  to 
assess  (weigh)  the  trustworthiness  of  the  informa¬ 
tion.  Also,  to  be  effective,  information  should  be 
collected  and  sent  in  a  timely  manner.  The  use  of 
authentication  techniques  such  as  a  Public  Key  In¬ 
frastructure  (PKI)  enable  us  to  ensure  agent  trust¬ 
worthiness. 


•  Secure  and  reliable  propagation  of  information  col¬ 
lected  by  agents:  A  temporally  or  spatially  iso¬ 
lated  view  of  attacks  can  give  the  wrong  impres¬ 
sion  regarding  an  overall  situation.  Propagation 
of  information  regarding  an  attack  on  one  target 
will  enable  heightened  sensitivity  at  other  poten¬ 
tial  targets,  so  that  temporally  and  spatially  dis¬ 
tributed  attacks  may  be  successfully  recognized 
and  detected  by  a  central  authority.  Furthermore, 
use  of  encryption  ensures  that  while  the  informa¬ 
tion  is  propagated  and  shared  among  allies,  it  will 
be  blocked  from  adversaries. 

•  Sharing  of  heterogeneous  information  (i.e. ,  infor¬ 
mation  from  different  sources):  Information  is 
gathered  from  various  sources.  For  example,  in  In¬ 
trusion  Detection  Systems  (IDS),  attacks  can  oc¬ 
cur  at  various  levels,  from  physical  components 
to  the  application  level.  Therefore,  agents  need 
to  gather  data  from  various  sources  such  as  log 
files,  anomaly  detectors,  profiling  data,  intelli¬ 
gence  sources,  etc.  We  need  a  way  to  integrate 
this  information  from  different  sources  for  more 
accurate  analysis  and  response.  To  render  the  in¬ 
formation  in  a  common  format,  we  use  XML  to 
define  common  data  formats,  and  rules  and  pro¬ 
cedures  for  sharing  information. 

•  Sharing  of  information  among  different  classifica¬ 
tions  in  an  MLS  environment:  Situational  aware¬ 
ness  requires  permissible  information  flow  of  need- 
to-know  information  only,  between  different  secu¬ 
rity  levels. 

•  Collecting  necessary  statistical  data  for  appropri¬ 
ate  strategic  responses:  To  use  agents  success¬ 
fully  in  intrusion  detection,  we  need  to  apply  dis¬ 
tributed  knowledge  networks  and  data  warehous¬ 
ing  techniques  to  the  infrastructure.  These  tools 
enable  operations  such  as  information  retrieval, 
transformation,  knowledge  discovery,  and  data  as¬ 
similation,  on  information  from  various  heteroge¬ 
neous  distributed  sources.  This  statistical  data 
can  also  be  used  in  developing  battle  space  de¬ 
cision  aids  for  information  warfare  purposes. 

•  Allowing  tactical  decision-making  and  responses 
from  lower-level  authorities:  In  a  network  centric 
environment,  decisions  may  need  to  be  made  im¬ 
mediately.  Our  distributed  infrastructure  allows 
intermediate  authorities  to  make  tactical  decisions 
regarding  certain  attacks  or  vulnerabilities  with¬ 
out  waiting  for  guidance/input  from  a  central  com¬ 
mand  (authority).  For  example,  having  received 
a  CERT  (Computer  Emergency  Response  Team) 
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advisory  of  a  new  vulnerability,  these  intermedi¬ 
aries  would  be  allowed  to  immediately  exert  reme¬ 
diation  efforts,  such  as  the  installation  of  a  patch 
or  patches  on  computers  under  their  administra¬ 
tive  control.  The  intermediaries  would  also  prop¬ 
agate  this  information  to  their  chain  of  command, 
so  that  the  central  authority  and  other  interme¬ 
diaries  could  gain  a  quick  understanding  of  the 
situation. 

•  State-of-the-art  visualization  tools  for  the  com¬ 
mand  center:  To  fully  cope  with  and  comprehend 
the  vast  amount  of  information  being  transmitted 
and  exchanged,  we  require  a  user-friendly  visual¬ 
ization  tool  that  displays  the  evolving  state  of  the 
network.  We  are  evaluating  current  visualization 
and  image  processing  technologies  to  use  them  in 
developing  unified  and  coherent  visualization  tools 
for  this  domain. 

2.2  Network  Situational  Awareness 

Although  many  Intrusion  Detection  Systems  (IDS) 
have  been  developed  commercially  and  are  deployed 
operationally,  their  use  has  not  decreased  the  num¬ 
ber  nor  the  severity  of  successful  attacks  on  DoD  sys¬ 
tems.  Information  networks  and  systems  are  essential 
to  network  centric  warfare  and  must  be  managed  and 
controlled  just  like  conventional  forces.  To  assess  the 
health  of  a  network  or  to  respond  to  an  intrusion  re¬ 
quires  the  correlation  of  incident  reports  from  different 
types  of  IDSs  that  monitor  different  components  in  a 
network  or  system,  and  have  different  confidence  lev¬ 
els.  Fusing  these  disparate  sources  of  incident  data 
presents  a  daunting  task  for  a  network  administrator. 
Additionally,  sensors  from  different  systems  monitor 
different  events  of  interest.  Security  alerts  and  intel¬ 
ligence  reports  must  also  be  factored  into  these  as¬ 
sessments.  System  and  network  managers  alike,  being 
overwhelmed  with  the  amount  of  data  and  the  diversity 
of  incident  reports,  are  unable  to  digest  all  the  infor¬ 
mation  in  order  to  develop  a  reasonable  response  to  an 
attack. 

The  Navy  needs  technology  that  can  manage  the 
propagation  of  intrusion  detection  information  among 
many  different  organizational  groups  and  to  ensure 
that  appropriate  information  is  shared  among  all  par¬ 
ticipating  entities.  This  information  will  be  processed 
and  analyzed  for  different  purposes  throughout  the  en¬ 
terprise.  Additionally,  certain  groups  have  authority  to 
direct  responses  to  these  attacks  and  to  direct  that  se¬ 
curity  patches  be  made  to  Information  Technology  (IT) 
equipment.  We  need  effective  ways  to  carry  out  secu¬ 
rity  patches  and  to  respond  rapidly  to  attacks  based 


on  the  severity  and  magnitude  of  the  attacks.  In  order 
to  coordinate  responses,  decision  makers  need  graphi¬ 
cal  representations  of  the  current  IT  situation,  which 
will  require  the  correlation  of  large  amounts  of  incident 
reports.  Being  able  to  include  intelligence  information 
in  the  decision  making  process  would  be  very  beneficial 
to  rapid  response  and  prevention  of  further  damage. 

In  SINS,  we  address  the  problem  of  analyzing,  filter¬ 
ing,  coordinating,  and  communicating  relevant  incident 
data,  to  address  the  following  requirements: 

•  Secure  communication  of  incident  reports  and  re¬ 
sponse  strategies  between  organizations. 

•  Effective  security  alert  approaches  to  ensure  that 
security  patches  are  applied  in  a  timely  manner. 

•  Confidence  that  the  appropriate  enterprise  protec¬ 
tion  posture  is  maintained  at  all  command  eche¬ 
lons. 

•  Integration  of  intelligence  data  and  reciprocal  IW 
situational  awareness  sharing  with  the  intelligence 
community. 

•  Assurance  that  the  security  management  infras¬ 
tructure  itself  is  trustworthy. 

3  Application  of  SINS  to  C2  Systems 

In  this  section  we  briefly  examine  how  the  network 
situational  awareness  of  SINS  is  applied  to  combat  ap¬ 
plications.  The  application  we  shall  use  as  an  exam¬ 
ple  is  the  Integrated  Marine  Multi-Agent  Command 
and  Control  System  (IMMACCS)  [10],  a  Multi- Agent 
Decision-Support  System  prototype  developed  for  the 
US  Marine  Corps.  We  begin  with  a  brief  introduc¬ 
tion  to  the  situation-aware  middleware  specification 
language  Secure  Operations  Language  (SOL)  [3]  and 
proceed  to  describe  how  functionality  of  IMMACCS 
may  be  implemented  using  our  middleware. 

3.1  A  Brief  Introduction  to  SOL 

Agents  are  created  in  a  special  purpose  synchronous 
programming  language  called  Secure  Operations  Lan¬ 
guage  (SOL)  [2,  3,  5].  A  SOL  application  comprises 
a  set  of  agent  modules,  each  of  which  runs  on  a  given 
host.  The  host  executes  an  agent  module  in  compli¬ 
ance  with  a  set  of  locally  enforced  security  policies.  A 
SOL  multi-agent  system  may  run  on  one  or  more  hosts, 
spanning  multiple  networks  and  multiple  administra¬ 
tive  domains. 
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A  module  is  the  unit  of  specification  in  SOL  and 
comprises  variable  declarations,  assumptions  and  guar¬ 
antees,  and  definitions.  The  assumptions  section 
includes  assumptions  about  the  environment  of  the 
agent.  Execution  aborts  when  any  of  these  assump¬ 
tions  are  violated  by  the  environment.  The  required 
safety  properties  of  an  agent  are  specified  in  the 
guarantees  section.  The  definitions  section  spec¬ 
ifies  updates  to  internal  and  controlled  variables. 

A  variable  definition  is  either  a  one-state  or  a  two- 
state  definition.  A  one-state  definition,  of  the  form 
x  =  expr  (where  expr  is  an  expression),  defines  the 
value  of  variable  x  in  terms  of  the  values  of  other  vari¬ 
ables  in  the  same  state.  A  two-state  variable  definition, 
of  the  form  x  =  initially  init  then  expr  (where  expr 
is  a  two-state  expression),  requires  the  initial  value  of 
x  to  equal  expression  init ;  the  value  of  x  in  each  sub¬ 
sequent  state  is  determined  in  terms  of  the  values  of 
variables  in  that  state  as  well  as  the  previous  state 
(specified  using  operator  PREV).  A  conditional  expres¬ 
sion,  consisting  of  a  sequence  of  branches  “  []  guard  — t 
expression” ,  is  introduced  by  the  keyword  “if”  and  en¬ 
closed  in  braces  ("{"  and  "}").  A  guard  is  a  boolean 
expression.  The  semantics  of  the  conditional  expres¬ 
sion  if  {  []rq  — »  exprj  []g2  — >  expr2  ...  }  is  defined 
along  the  lines  of  Dijkstra’s  guarded  commands  [8] 
-  in  a  given  state,  its  value  is  equivalent  to  expres¬ 
sion  expr):  whose  associated  guard  <7,;  is  true.  If  more 
than  one  guard  is  true,  the  expression  is  nondetermin- 
istic.  It  is  an  error  if  none  of  the  guards  evaluates 
to  true,  and  execution  aborts.  The  case  expression 
case  expr  {  []rq  — >  exprx  []ri2  — >  expr2  ...  }  is  equiv¬ 
alent  to  the  conditional  expression  if  {  [](expr  == 
Vi)  — >  expr-L  [](expr  ==  Vo)  —t  expr2  . . .  }.  The  con¬ 
ditional  expression  and  the  case  expression  may  op¬ 
tionally  have  an  otherwise  clause  with  the  obvious 
meaning. 

3.2  Issuing  a  Call  For  Fire 

The  Fires  Agent  of  IMMACCS  responds  to  “Call 
For  Fire”  (CFF)  messages.  The  following  are  the  log¬ 
ical  rules  associated  with  the  functionality  of  issuing 
a  CFF  within  IMMACCS.  An  agent  may  issue  a  CFF 
only  if  the  forcecode  is  “not  friendly”  and  the  status  of 
the  locked-in  radar  is  “ACTIVE” .  This  requirement  is 
captured  by  the  following  rule  in  the  ACE  front-end: 

if  Radar . forceCode  ==  <friendly>  kk 
Radar . status  ==  ACTIVE 

then 

CallForFire. target  =  name (Radar) 

CallForFire . controlMethod  =  WHEN  READY 
endif 


deterministic  module  FiresAgent  { 
functions 

target_size  =  20; 
type  definitions 

integer  in  [-20:100]  ratings; 
monitored  variables 
integer  CEP,  ECR; 
controlled  variables 
ratings  rating; 
definitions 

rating  =  initially  100  then 
if  { 

□  ECR  <  target_size  ->  PREV(rating)  -  10 

□  CEP  <  ECR  ->  PREV(rating)  -  5 

□  CEP  >  ECR  ->  PREV(rating)  -  10 
otherwise  ->  PREV(rating) 

> 

}  //  end  module  FiresAgent 

Figure  2.  A  SOL  agent  to  calculate  the  rating 
of  a  weapon. 


3.3  Weapons  Selection 

The  Fires  Agent  is  also  responsible  for  selecting  the 
best  weapon  that  is  available,  deliverable,  and  accept¬ 
able.  The  “rating”  of  a  given  weapon  is  based  on  the 
Circular  Error  of  Probability  (CEP),  Effective  Casualty 
Radius  (ECR),  availability,  and  Rules  of  Engagement 
(RoE).  A  (subset  of)  the  requirements  associated  with 
this  function  is  captured  by  the  following  ACE  rules: 

if  Munitions .ECR  <  TargetSize 
then  rating  =  rating  -  10 
endif 

if  Munitions . CEP  >  Munitions .ECR 
then  rating  =  rating  -  10 
endif 

if  Munitions . CEP  <  Munitions .ECR 

then  rating  =  rating  -  5 

endif 

The  above  rules  are  translated  by  ACE  into  SOL  as 
shown  in  Figure  2.  The  formal  semantics  of  SOL  serves 
as  the  basis  for  analysis  and  transformation  techniques 
for  SOL  specifications,  such  as  abstraction,  consistency 
checking,  verification  by  model  checking  or  theorem 
proving,  and  automatic  synthesis  of  agent  code  [4], 
For  example,  application  of  the  tool  SOLver  on  the 
above  SOL  specification  will  establish  (with  mathemat¬ 
ical  certainty)  that  it  is  free  of  ambiguity  (i.e.,  it  spec¬ 
ifies  exactly  one  action  in  any  situation). 
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4  Conclusions  and  Operational  Payoff 

In  this  paper  we  show  how  SINS  provides  an  in¬ 
tegrated  formal  framework  for  the  construction  of 
situation-aware  command  and  control  applications.  In 
particular,  we  examine  the  requirements  of  Network 
Situational  Awareness  for  Naval  C2  and  combat  sys¬ 
tems.  The  underlying  formal  framework  of  SINS  serves 
as  the  basis  for  developing  robust,  efficient,  and  recon- 
figurable  applications.  Based  on  this  framework,  we 
are  currently  developing  a  suite  of  analysis  and  trans¬ 
formation  tools  for  SOL,  and  verification  tools  such  as 
automatic  invariant  generators  and  checkers,  theorem 
provers,  and  model  checkers.  We  currently  have  a  com¬ 
piler  for  SOL  which  generates  Java  code  suitable  for 
execution  on  multiple  hosts.  Planned  extensions  to  the 
compiler  include  support  for  fine-grained  access  con¬ 
trol  and  support  for  transactions,  fault-tolerance,  load 
balancing,  and  self-stabilization. 

The  SINS  infrastructure  provides  a  robust  applica¬ 
tion  development  platform  upon  which  networked  C 2 
for  Combat  Applications  may  be  developed,  tested,  and 
fielded.  SINS  provides  a  seamless  flow  of  information, 
with  the  desired  quality  of  service,  which  is  required 
to  support  not  only  horizontally  distributed  nodes  but 
also  vertical  Command  Echelons  from  the  Commander- 
in-Chief  (CINC)  to  the  Unit  level.  The  SINS  infras¬ 
tructure  is  fully  end-user  programmable  and  reconfig- 
urable,  with  reconfiguration  times  measured  in  minutes 
instead  of  days  or  weeks.  SINS  will  provide  comman¬ 
ders  and  operators  of  networked  C 2  systems  the  ability 
to  request  for  and  obtain  the  quality  of  service  required 
to  achieve  the  desired  mission  objectives.  SINS  is  de¬ 
signed  to  be  highly  secure,  having  been  built  from  the 
ground-up  with  quality  control  and  high  assurance  in 
mind.  Additionally,  SINS  is  provably  secure,  i.e. ,  free 
of  flaws  with  mathematical  certainty.  Another  impor¬ 
tant  criterion  we  address  in  SINS  is  efficiency.  Espe¬ 
cially  in  a  web-enabled  and  highly  mobile  setting,  ex¬ 
changing  required  information  and  only  the  required 
information  saves  bandwidth  and  reduces  latency. 
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